Industry started using the computer programming language COBOL (Common Business Oriented Programming Language) over 30 years ago. After three decades, COBOL has managed to achieve a pervasive presence in nontechnical business applications including, for example, insurance and banking. One ubiquitous element of COBOL programs and other computer language programs written for business applications is a date code. A date code is a six digit sequence representing a day, a month, and a year. The date code is usually formatted as YY-MM-DD or MM-DD-YY, where YY is a two digit year code, currently assumed to be in the twentieth century (e.g., 89 represents 1989), MM is a two digit month code (e.g., 11 represents November), and DD is a two digit day code. Thus, the date code 89-11-25 represents the 25.sup.th day of November, 1989. COBOL programs and other computer language programs use date codes to determine a wide variety of information.
Date codes are responsible, for example, for determining when checks should be issued, when insurance policies expire, and when interest should be credited to an account. In fact, it is difficult to conceive of a COBOL business application that does not use a date code. For a variety of reasons, traditional COBOL business applications have almost always exclusively used two digits to represent a year. This was particularly true in the 1960's, 70's, 80's, although much COBOL code written in the 90's also use a two digit year representation of the date code. Therefore, as it stands, a significant percentage of COBOL business applications cannot understand, encode, or operate in general with any years subsequent to the year 1999.
Furthermore, reports concerning COBOL applications that are failing today, well before the year 2000, are becoming more commonplace. One source of these failures is COBOL program code that generates a year that the program cannot interpret correctly, possibly by adding offsets to years that it can understand. For example, a COBOL program calculating the expiration date of a five year insurance policy begun in 1997 will come up with the result 1902 (97+05=102, and truncated to two digits=02). In other words, the insurance policy begun today expired 95 years ago.
Industry analysts estimate that 90% of all COBOL business applications will generate critical errors (for example, canceling insurance policies prematurely) because of their year 2000 incompatibility. The analysts further estimate that some corporations, particularly the larger ones, will each spend between $50-$100 million trying to rewrite their COBOL business applications to understand years in the twenty-first century. A total price tag of over $500 billion has been placed on correcting, rewriting, and updating all COBOL business applications for year 2000 compliance. A significant part of the total cost includes the need for an additional 200,000 COBOL programmers to join the ranks of the existing pool of nearly 1,000,000 who will attempt to bring COBOL business applications worldwide into conformance.
As the new millennium approaches, corporations face the significant challenge of correcting existing applications to handle the expanded date formats of the 21st century. The challenge is far greater than simply updating COBOL source code, however, since date code incompatibilities exist in a number of problem areas in addition to the source code itself. These problem areas include: COBOL compilers and other computer language compilers that only support two digit year codes, data files and data bases containing information including, for example, insurance records and bank deposits, and operating systems and system clocks that do not support dates greater than 1999. Thus, even if a corporation could find qualified COBOL programmers to update their COBOL business applications, the length of time needed to examine all the possible problem areas will be far greater than most corporations realize. Because of the complexity of the COBOL business applications, and their significant reliance on time-based calculations, industry cannot wait until 1999 for a solution.
A solution is needed immediately since a shortage of COBOL programmers already exists and is worsening, applications are starting to fail today, and programming costs will rise significantly over the next few years as the demand for COBOL programmers far outstrips the supply. Furthermore, the year 2000 problem spans all computer platforms and operating environments, all of which must be corrected.
A number of companies have attempted to provide solutions for the year 2000 problem. Unfortunately, most of these solutions require changing all aspects of a particular COBOL business application, including source code, data files, and even the COBOL compiler itself. One common approach to solving the date code problem is expanding the date code to use a four digit year code instead of a two digit year code. Thus, instead of representing Nov. 25, 1989 as 89-11-25, the new date code would represent Nov. 25, 1989 as 1989-11-25.
One difficulty inherent in switching to a four digit year code representation is that old data files would no longer be compatible with the revised format. Thus, corporations would also have to find a way to convert all of their old data, which may consist of decades of transactions and millions of records, to the new format. Furthermore, most of the COBOL business application source code would have to be modified as well, in order to properly read, store, and manipulate the larger year code, as well as perform mathematical operations with it. Another difficulty inherent with the four digit year code is that many COBOL compilers today only support the standard two digit year code. Therefore, switching to a four digit year code requires changes not only to the data files and COBOL source code, but also to the COBOL compiler itself. Changes to the COBOL compiler may not even be possible for most corporations because they use COBOL compilers licensed from, and under the control of, third parties.
Therefore, a need remains for a solution to the year 2000 COBOL problem which overcomes the disadvantages discussed above and previously experienced.